ADFA-4128 (9/11): quickbuild:daemon — the incremental compile service - #1721

… d8 + stable-ids surfacing

Review findings (PR #1721, all four Important items):

1. Stale shrunk-snapshot on re-configure -> configure fingerprints the classpath
   jars (path+size+CRC) and wipes shrunk-classpath-snapshot.bin plus ic/ when the
   bytes changed, keeping them when identical. Covered by IncrementalCompilerTest
   "re-configuring over an in-place rewritten classpath jar discards the stale
   shrunk snapshot" and its byte-identical keep-warm companion.

2. "Deployed" baseline that no deploy ever acks -> deployedOutputs renamed to
   lastGoodOutputs with honest KDoc, and a compile declaring EVERY source changed
   now rebaselines: the output diff runs against nothing and reports the whole
   tree, giving clients a wire-compatible recovery after a failed dex/deploy.
   Covered by IncrementalCompilerTest "declaring every source changed rebaselines
   - the whole output tree is reported changed". ROUTED(qb-08 core-orchestration
   / qb-11 app): the orchestrator must still force a full-changed compile
   (ChangedFiles.Unknown) after a failed dex/deploy; today it only re-queues the
   batch. No protocol-module change.

3. d8 diagnostics not captured -> a DiagnosticsHandler proxy is installed via
   D8Command.builder(handler); collected error diagnostics are appended (bounded)
   to the Failed message instead of the bare "Compilation failed to complete".
   Covered by DexToolEdgeTest "a d8 failure surfaces d8's own error diagnostics,
   not only the generic message" (runtime-compiled fake r8, runs untethered).

4. Silent stable-ids degrade -> relink fails a named-but-missing stableIds file
   before aapt2 runs; only an explicit null links unpinned. Covered by
   Aapt2LinkEdgeTest "a named but missing stable-ids file fails the relink
   instead of silently linking unpinned".

Tests are written to fail without their fix but were NOT executed here (no-build
constraint on this fix pass); verify with :quickbuild:daemon:test.

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Kj9YeCDHGp9DU8LPtfWJ7W

- F1721-1 fail the relink when more than one resource root is given
- F1721-3 release the kotlinc session and D8 each DaemonServiceOpsTest opens

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01FstXxJ5cwWPcvmhZ9vJgJ7

…, diagnostic caps

Applies the fix-now items from the 2026-08-31 review triage (items 1, 2, 4,
5, 6, 7, 10, 11; 3/8/9 deferred to followup tickets).

- IncrementalCompiler init commits the classpath fingerprint LAST, after the
  per-jar snapshots it describes exist; a throw mid-construction now leaves
  the previous fingerprint so the retry re-detects the change and wipes,
  instead of assureNoClasspathSnapshotsChanges trusting snapshots that were
  never built.
- JavaCompileStep passes "--release" JVM_TARGET (shared constant, now
  internal in IncrementalCompiler): pins javac's bytecode AND platform APIs
  to kotlinc's -jvm-target 17, so a JDK-21 device no longer mixes major 65
  and 61 in one tree or resolves java.* against the host JDK's modules.
- FinalStripper passes the reader to ClassWriter (copy-through; roughly
  halves the rewrite cost) and its KDoc now says so. The identical change in
  gradle-plugin's ClassOpener lands on qb-10 in lockstep.
- Aapt2Link caps parsed diagnostics at 50 plus a "+K more" marker,
  mirroring DexTool's output-bounding rationale.
- The -nowarn asymmetry (kotlinc warnings suppressed, javac's kept) is now
  stated at the flag, on Result.Success.warnings, and the dead
  logger.warnings mapping is gone.
- deleteJavaOutputs logs the unresolvable-stem skip instead of silently not
  sweeping stale outputs.
- DaemonMain shuts the service down in a finally, covering the
  fatal-rethrow exit path.
- DaemonService's compile-ok log line reports lastJavaAbiChange when
  non-empty, delivering that field's documented purpose.

Tests: fingerprint-ordering and diagnostic-cap tests verified RED against
the pre-fix behavior (temporary revert), then green. The --release test
passes vacuously on the JDK-17 host and goes red on a JDK-21 toolchain -
red-first is not demonstrable here without a second JDK. DaemonMain's
finally has no unit test (main() wires real process stdio). Full
:quickbuild:daemon:test green.

Also: plain-language pass over the comments added by these fixes

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01STCsdMzx9daNBcqMN424Ci

Akash's 2 September round, led by the argfile break he verified against
build-tools 37.0.0.

- A link whose resource paths contain whitespace keeps the inline -R pairs
  whatever the input count. The argfile format splits on whitespace and has no
  escape for it, so one space truncated that input and every later one - and
  the project directory reaches these paths unsanitised, with "My Application"
  the default new-project name. Pinned by a test that fails without the guard.
  #1721 (comment)
- The inline path deletes a link-inputs.txt an earlier link left behind, which
  nothing else swept.
  #1721 (comment)
- The unswept-output warning reaches the daemon log. It went to compileLog,
  which defaults to a no-op and which DaemonService cannot pass without also
  taking kotlinc's verbose channel, so the warning has its own parameter.
  #1721 (comment)
- javac's options are assembled by an internal function and --release is
  asserted on the argv. The host JDK emits the same class file version either
  way, so no compile-and-read test can fail when the flag is dropped.
  #1721 (comment)
- CollectingLogger's KDoc no longer says the result is built from warnings as
  well as errors; -nowarn means no real compile drives that channel.
  #1721 (comment)

Not fixed here: the FinalStripper/ClassOpener parity test and the
DaemonService reconfigure-mutates-the-live-session deferral. Both are
ticket-only follow-ups; the ticket text is drafted with this round's replies.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

…annot be skipped

Three findings on IncrementalCompiler, all in the same file.

Bound the diagnostics (3926561750). kotlinc emits one unresolved-reference error
per use site, so deleting a dependency yields hundreds to thousands - and the
whole list rides one protocol line into a phone-screen panel. DexTool and
Aapt2Link already cap for this reason; this is the third and most frequently
exercised path. Reuses Aapt2Link's shape: the first MAX_DIAGNOSTICS entries plus
one "+K more ... elided" marker.

Move the lastJavaAbiChange reset into compile() (3926561777). It lived in
kotlinFilesToCompile, which a source set with no Kotlin returns before reaching,
so the ok line's javaAbiChange tail could carry a previous compile's set.

Pin the unresolvable-stem warning (3926564720). The routing was already fixed;
nothing asserted the message is emitted at all, which is how the first version
of that fix reached head with the warning going to a no-op log.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

Four guard fixes across the op paths.

Reject a directory classpath entry at configure (3926561762). A directory
contributes only path + File.length() to the fingerprint, and length() on a
directory is a filesystem constant - so an in-place class rewrite inside one
leaves the staleness guard silent and ships stale dependents. Taking the cheap
half: fail visibly rather than fingerprint directory contents.

Compare the ABI snapshot against its own map (3926561767). Both sides are keyed
by absolute path, so one repeated input left the snapshot permanently one short
and every later compile took the unknown-ABI arm - the feature's headline claim
quietly inverted. The existing test pinned the old behaviour as a conservative
contract; a repeat is not an unparsed file, so it is corrected here.

Resolve the r8 OutputMode constant with firstOrNull (3926561771). first {} throws
NoSuchElementException, which is neither catch arm, so a layout mismatch reached
the user as "internal: ..." instead of the dex failure Result.Failed promises.

Blank-normalise stableIds (3926561784), matching configure's tool paths: a blank
became File(""), and the relink hard-failed naming a directory nobody configured.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

…re the timeout verdict

Move the readLine inside the try (3926561781). Its comment named "a pathological
line" as what it covers, but the read is the call that allocates the line, so an
OutOfMemoryError from it escaped serve and exited the JVM - which CoGo reads as
daemon death. The comment's claim about its own scope is now true.

Report an aapt2 timeout only when the kill hit a live process (3926561791).
waitFor(timeout) also returns false for a child that exited just after the wait
expired, and destroyForcibly then no-ops, so a link that finished could be
failed as timed out. The kill, not the wait, is now what says a link was cut
short.

Record the argv headroom the argfile threshold was never measured against
(3926561741). Measured on this Mac: a Material/AndroidX corpus app links 292
resource inputs, ~46 KB of argv re-rooted on a device project path; CoGo's own
app module links 1475, ~229 KB. The host's exec ceiling for those paths is 5990
-R pairs (~946 KB); Android's is bionic's RLIMIT_STACK/4, ~2 MiB. So the budget
is not reachable at real project sizes, the whitespace fallback endangers
nothing, and the argfile is a size optimisation rather than a guard. Documented
rather than reworked - see the reply on that thread.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

…README its siblings have

Correct the javacOptions comment (3926561757). It claimed --release pins the
platform API surface as well as the bytecode level; it does not. java.* resolves
against the JDK's own release-17 ct.sym signatures, and android.jar reaches the
compile only through -classpath, which the platform shadows - so a .java calling
a JVM-only API compiles green here and is rejected by AGP's JavaCompile.

The proposed remedy is not taken. javac 17 answers -bootclasspath at this target
with "option --boot-class-path not allowed with target 17" [measured on this
Mac], and dropping --release widens the surface to the host JDK's whole module
set rather than narrowing it. Pinning the API to the project's android.jar is a
design call, not a flag swap; the comment now states the gap instead of denying
it.

Add quickbuild/daemon/README.md (3926561798), matching the structure and depth
of the core and protocol module READMEs: the never-exit rule, the serve loop,
the session lifecycle, the two-pass compile and its warm-state guard, dex and
relink, and the traps. Indexed from quickbuild/README.md's two tables.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

… suggested fix

Review asked for the gap to be visible at the line: a project path with a space
keeps the inline -R form whatever the input count, so a far larger app than any
Quick Build targets today would fail the link. Measured headroom is in the KDoc;
the fix (staged whitespace-free symlinks) waits until an app that size exists.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

…nd pin two unpinned arms

Three review gaps in the daemon, plus one investigation that produced no code.

The d8 diagnostics collector's pass-through arm returned null for any method it
has no arm for. null is not a legal answer for a primitive return type -
isInstance is false for every primitive, so an int-returning method falls
through - and the proxy unboxes it into a NullPointerException raised inside
d8's own call, where it reads as a d8 bug. It now throws, naming the method and
its return type, which is the same policy this branch already applies to inputs
the daemon cannot answer for. A guessed default was the other option and is
worse: a silent wrong answer to a question we do not understand.

The aapt2 watchdog's kill check was tested in isolation but nothing consulted
that test's subject: reverting the one line that used it left every test green.
The verdict - wait expired AND a live process killed - moves into
watchdogTimedOut, and a stubbed Process drives the case a real one cannot, a
child that exits just after the deadline.

The Java ABI snapshot's completeness check had no test on its null side either.
A path with a redundant segment is the reproducible way in: the map is keyed by
absolute path, javac reports the unit under the path it resolved, the lookup
misses, and the file is dropped.

No code for the --release question, which was investigated rather than
answered. Every documented way to narrow the platform surface was tried on
javac 17 against android-36's android.jar: -bootclasspath is refused above
target 8, --system none cannot find java.lang because android.jar is not a
system image, and --release with --patch-module java.base still compiles
ProcessHandle green. Only -source 8 with -bootclasspath narrows it, at the
bytecode level this flag exists to prevent. AGP does call setBootstrapClasspath,
but javac refuses that flag above target 8 and this IDE's templates generate
Java 17 projects, so the standard build looks equally permissive rather than
stricter. The comment now records that instead of asserting a gap no run has
shown. An AGP build on such a project would settle it.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

…stead of refusing it

The round-3 fix made configure refuse any classpath entry that is not a file.
That breaks Quick Build for every Kotlin project: the Gradle plugin writes the
variant compile classpath verbatim, and for a Kotlin module that includes the
module's own build/tmp/kotlin-classes/<variant>, a directory javac needs.
Reproduced twice on the A56.

The refusal existed because a directory was fingerprinted by its own length,
which is a filesystem constant, so an in-place class rewrite inside one left the
staleness guard silent and shipped stale dependents. This takes the reviewer's
other option instead: a directory entry is fingerprinted by walking it and
folding each file's relative path, size and CRC in, sorted so the walk order
cannot change the answer. A file entry's fingerprint text is unchanged.

The rejection and its comment are gone, and the test that pinned the rejection
now pins the acceptance.

Tests: a class rewritten in place inside a directory entry changes the
fingerprint; an unchanged directory entry fingerprints the same, so a
re-configure still keeps the warm caches; configure accepts a classpath holding
a directory. On the old code the first failed with the directory line reading
"library-classes|96|-1" on both sides, and reinstating the rejection fails the
third.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A

…entry, not that it rejects one

The session table, the fingerprint paragraph and its rationale all said configure
refuses a directory classpath entry. It does not: the Gradle plugin writes the module's
own kotlin-classes dir into the variant classpath, and the guard fingerprints such an
entry by its sorted contents. A reader checking the stale-classpath guard was being told
the one wrong thing.

Review: #1721 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…e output drain

The kill is what closes the child's pipe and wakes the request thread's read, so a flag
stored after the kill could land after that thread had read it: a link cut short at the
deadline then reported as an ordinary link failure with nothing naming the timeout. The
flag now goes in between the liveness check and destroyForcibly.

The drain itself was the one unbounded step on the aapt2 path: readText() kept the whole
merged output while every consumer downstream is capped. It now keeps 256K characters,
drains the rest so the child can exit, and ends with a marker naming what was dropped.

Review: #1721 (comment)
Review: #1721 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…ilure naming it

openClasses ran outside dex()'s try, so ENOSPC mid-mirror or a class file from a newer
compiler than ASM knows escaped as an internal error naming no file. The pass reads and
rewrites every class file on every dex, which makes it the likelier place to fail than d8.
The try now covers it, and a per-file failure carries the class path.

Review: #1721 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

A null snapshot sends every later compile in the session down the full-Kotlin-recompile
arm, and from the daemon log that was indistinguishable from a slow device. snapshot()
now takes the compiler's warn channel and names the exception before answering null.

Review: #1721 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…ingerprint

The fingerprint covered the classpath but not compilerPluginJars, so a configure with the
same classpath bytes and a different plugin set kept IC caches seeded under the previous
plugin - and the next compile asserted assureNoClasspathSnapshotsChanges(true) over them.
Unreachable through today's session-fixed plugin list, and this keeps it that way.

Review: #1721 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…he marker counts

javac's list went through whole on both the failure and the success path while the Kotlin
and aapt2 paths cap at 50. Both javac sites now cap, the marker names the producing tool
instead of always saying Kotlin, and the README's "all three tool paths cap" sentence now
says what each of the four actually does.

Review: #1721 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…he review out of them

Both TODOs named the whole epic, and one quoted the review inside shipped code. Each now
states its constraint directly - the argfile workaround must copy, not symlink, because the
phone's emulated storage refuses symlinks - and carries an ADFA-XXXXX placeholder for the
follow-up ticket to be filed before push.

Review: #1721 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…vac accepts

The comment claimed the standard build was probably as permissive as --release. Measured
on a Java-17 template project with AGP 8.11 and Gradle 8.14.3: AGP's JavaCompile rejects
ProcessHandle with "cannot find symbol", because it passes --system with a jlink'd image
built from the platform's core-for-system-modules.jar. The paragraph now says so, and
names the follow-up (ADFA-XXXXX placeholder until filed).

Review: #1721 (comment)

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…uccess stays warnings

capped() always appended a Severity.ERROR marker. On the success path that marker rode
Result.Success.warnings into the response, DaemonProcessClient kept it as ERROR, and the
app printed "error: +N more javac diagnostics elided" under a "reloaded" line - while the
core's Success and Deployed KDocs promise no ERROR ever rides them. The marker now takes
the worst severity present: ERROR when the list has one, WARNING otherwise.

New test compiles 60 [removal] warnings successfully and asserts the capped list is all
WARNING.

Adversarial review 2026-09-04, finding #29 on 7a21dbb2e.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…s cap

capped() took the first MAX_DIAGNOSTICS entries in javac's source order, so a
failed compile whose first 50 messages were warnings reached the panel as
"failed" with every error elided. Errors now go first and the cap trims the
warnings; each severity keeps its own order, and the marker's severity rule is
unchanged. The new edge test buries one unresolved type behind 60 [removal]
warnings and fails on the old code with the leading entry a WARNING.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

…omments

JavaCompileStep -> ADFA-5502, Aapt2Link -> ADFA-5503, IncrementalCompiler -> ADFA-5504.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2